NAME¶

amtapetype - generate a tapetype definition by testing the device directly

SYNOPSIS¶

amtapetype [-h] [-c] [-f] [-p] [-b blocksize] [-t typename] [-l label] [-o config_overwrite] [device]

DESCRIPTION¶

amtapetype generates a tapetype entry for Amanda by testing the device directly

OPTIONS¶

-h

-c

-f

-p

-b blocksize

-t typename

-l label

-o configoption

EXAMPLE¶

Generate a tapetype definition for your tape device:

% amtapetype -f /dev/nst0

NOTES¶

If the device cannot reliably report its comprssion status (and as of this writing, no devices can do so), hardware compression is detected by measuring the writing speed difference of the tape drive when writing an amount of compressable and uncompresseable data. If your tape drive has very large buffers or is very fast, the program could fail to detect hardware compression status reliably.

Volume capacity is determined by writing one large file until an error, interpereted as end-of-tape, is encountered. In the next phase, about 100 files are written to fill the tape. This second phase will write less data, because each filemark consumes some tape. With a little arithmetic, amtapetype calculates the size of these filemarks.

All sorts of things might happen to cause the amount of data written to vary enough to generate a strange file mark size guess. A little more "shoe shining" because of the additional file marks (and flushes), dirt left on the heads from the first pass of a brand new tape, the temperature/humidity changed during the multi-hour run, a different amount of data was written after the last file mark before EOT was reported, etc.

Note that the file mark size might really be zero for whatever device this is, and it was just the measured capacity variation that caused amtapetype to think those extra file marks in pass 2 actually took up space.

AUTHORS¶

Dustin J. Mitchell <dustin@zmanda.com>

Jean-Louis Martineau <martineau@zmanda.com>